test(ofrep): run the provider conformance suite against flagd's OFREP API - #414

… API

Adopts the OpenFeature provider conformance suite in the OFREP provider.

No new infrastructure. flagd serves the OFREP API on port 8016 alongside its own
protocols, and flagd-testbed's compose file already publishes it, so the OFREP
provider runs against the existing testbed, seeded with the same canonical flag
set, driven through the same launchpad control API as the flagd suites. Running
two providers against one backend is the point of a cross-provider conformance
suite: a difference in the results is a difference an application would see when
it switches provider.

tests/e2e/flagd_container.FlagdContainer would have been the natural thing to
reuse and is not importable here -- a package's tests are not part of its
distribution -- so tests/tck/testbed.py drives compose directly. What it
duplicates is deliberately minimal: compose up, read two mapped ports, poll
/readyz. This is a concrete instance of the "no shared containerised-backend
helper" gap the TCK's README records.

Two capabilities, both on the strength of a line of provider code rather than of
a green run: OBJECT and STRICT_NUMERIC_TYPING. The same two the Go and Java OFREP
adoptions reached independently, from the same architecture.

Every omission is a fact about the provider. OFREPProvider is stateless -- it
holds a requests.Session and a rate-limit timestamp, and nothing else survives
between evaluations. It does not override initialize, so it inherits
AbstractProvider's, which is `pass`, and it never emits: `_on_emit` is not called
anywhere in the provider. So EVENTS, STALE and CONFIGURATION_CHANGE have nothing
behind them, and UNAVAILABLE_INIT is false in the strong sense -- a provider
pointed at a closed port reaches READY, because the SDK's registry dispatches
PROVIDER_READY around an initialize that does nothing. events.feature and
lifecycle.feature are gated at feature level and skip with their reasons; 24 of
the 29 scenarios run.

@lifecycle, which lands on the TCK branch this is stacked under, would also be
withheld once it is available here: nothing contacts the backend before the first
evaluation, so initialisation has no outcome to observe. That capability was
split out of EVENTS precisely so a stateless provider can decline it accurately,
and this is the case it was split out for.

One scenario is marked xfail(strict=True): boolean-flag requested as an Integer.
OFREP is untyped on the wire -- the request carries no type and the backend
returns the JSON value regardless -- so the whole type check is the provider's,
and it is isinstance(value, int), which bool is a subclass of in Python. The
value True comes back with reason STATIC and no error code where the
specification requires the code default and TYPE_MISMATCH. The SDK client
type-checks the same way, so this is the provider-side half of
open-feature/python-sdk#619 and fixing one half is not enough. Strict, so the
marker fails the suite once it starts passing rather than lingering as a lie.

Recorded as a finding: POST /start returns before the backend serves the flag
set. The control API specifies that /start reseeds flag state; it does not
specify that it returns only once that state is being served, and flagd-testbed's
launchpad returns as soon as flagd answers /readyz, which is roughly 40ms before
its file sources are in the flag store. The flagd suites never see this because
both resolvers block inside initialize until the stream is up or the ruleset has
synced, absorbing the window. A stateless provider is the first adopter with no
initialisation to hide a backend's warm-up behind, and its first evaluation lands
squarely in the gap -- reported, before the fix, as FLAG_NOT_FOUND on every flag.
SettledControl closes it by delegating to HttpControl and then polling the public
OFREP endpoint until the flag set is actually served. It manipulates nothing and
weakens no scenario, but "reseeded" and "serving" should be the same instant in
the control API contract, and until they are this belongs in the adoption.

23 passed, 5 skipped, 1 xfailed.

Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>